If those JVMs are different, Java LS will update all projects.
The issue can't be reproduced when starting VS Code with JDK 11 and without java.configuration.runtimes.

The reason is probably from the following code. It will bring some unnecessary project update event if java.configuration.runtimes explicitly sets a different JDK as default.

https://github.com/eclipse/eclipse.jdt.ls/blob/791f30ed63f9960d5ad7dc2e9ba3b9e203cf2b9a/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/JVMConfigurator.java#L306-L308

Reproduce steps:

• set java.home is set JDK 11
• add a JDK 17 to java.configuration.runtimes, and set its default to true.
• reopen vscode on a Java project (e.g. eclipse.jdt.ls), you will see the log like "!MESSAGE defaultVMInstallChanged -> force update of org.eclipse.jdt.ls.core".

The reason is probably from the following code. It will bring some unnecessary project update event if java.configuration.runtimes explicitly sets a different JDK as default.

Right!
The -Djava.ls.doNotSetDefaultJVM=true fixes it.

How would this work on the client side ? Would the client need to set -Djava.ls.doNotSetDefaultJVM=true if they don't detect a setting for java.configuration.runtimes where default: true is used ? Is there any way to fix this on the language server side by addressing the TODO comment ?

How would this work on the client side ? Would the client need to set -Djava.ls.doNotSetDefaultJVM=true if they don't detect a setting for java.configuration.runtimes where default: true is used ? Is there any way to fix this on the language server side by addressing the TODO comment ?

It could be done in the Eclipse PDE support extension.

@testforstephen , can this be used to avoid having vscode-pde rebuilding the workspace unnecessarily ? How would vscode-pde set this property, since it only contributes to JDT-LS via bundles, and at that point it's probably too late to set the system property.

@testforstephen , can this be used to avoid having vscode-pde rebuilding the workspace unnecessarily ? How would vscode-pde set this property, since it only contributes to JDT-LS via bundles, and at that point it's probably too late to set the system property.

Yes, vscode-pde doesn't have a good way to specify such property. We need a better approach that does not depends on system property to fix this.

Ok, so then we can't merge this PR in the current form.

What we really need is a nice way for JDT-LS to detect whether a bundle extension wants to handle setting the runtime, and if so, simply avoid setting it.